I should warn that it does mess up the layout somewhat.

Here's how the unscaled window looks on my 4K monitor:

Here's the window with the scaling patch. The layout is messed up a bit, but the text is readable and everything is crisp.

And here's what happens if I multiply FontGlobalScale but leave ImGuiBindings intact. The layout is messed up in a different way, and the fonts are blurry (while with the patch as implemented in the PR, the fonts are sharp).

I assume you'll know what to do, though. For me, it's not a deal breaker.

Added a PR on Maia-Everett:wayland-hidpi for changes to allow everything to scale. It was a bit too much to add as a series of comments, since it touches 22 files in all.

I am encountering one oddity, though. When I check the scaling factor being applied, I'm getting 1.5875, despite having scaling set at 1.5 in kde. Not sure where it's getting that number.

I am encountering one oddity, though. When I check the scaling factor being applied, I'm getting 1.5875, despite having scaling set at 1.5 in kde. Not sure where it's getting that number.

I've added verbose logging for that, and it seems SDL calculates DPI based on the physical dimensions of the screen. For my primary monitor, it reports 162.56x161.3647, whereas for scaling purposes I'd want 192 DPI reported (since my desktop uses 200% scaling with 4K resolution 3840x2160).

Querying the desktop environment itself will return the value we actually want. And how do you obtain the scaling value the DE uses? Lol, lmao. By using a variety of DE-specific methods of various levels of hackishness, apparently.

I'll change it.

Just curious, is there nothing in Veldrid that can be used for that?

Just curious, is there nothing in Veldrid that can be used for that?

Unfortunately, no. Grepping scale across the Veldrid source returns nothing relevant.

For KDE specifically, my plan is to query kscreen-doctor -j and then parse the JSON output for the scaling factor of the monitor with x: 0, y: 0 (it always exists). It returns the correct fractional scaling value.

For GNOME and other DEs, I don't know a reliable way to query fractional scaling, so we can fall back to gsettings get org.gnome.desktop.interface scaling-factor, then xrdb -query, and finally SDL (which returns an incorrect but not-too-badly-incorrect value), in that order.

Pushed new commits:

• Scaling is now obtained from the desktop environment if possible, falling back to SDL.
• The news banner is also scaled.

Thanks for your scaling support, @rankynbass! The PR is now feature-complete.

Here's how it looks at 200% scaling in KDE:

and at 150%:

This fix only applies to XWayland. Native Wayland rendering when running with SDL_VIDEODRIVER=wayland is still blurry, but that's a separate issue.

It turns out that with native Wayland, SDL natively supports HiDPI scaling and resizes the window drawable accordingly while still accepting and reporting an unscaled window size — but only if you pass it SDL_WindowFlags.AllowHighDpi, which Veldrid doesn't set (I'll file an issue for that).

So all that's needed to do is to obtain that scale factor from SDL and pass it to OpenGL and ImGUI so they correctly scale the viewport and drawing respectively, which I've now done. So as of the latest commit, HiDPI scaling correctly works with both XWayland and native Wayland with no blurriness.

Edit: I've reverted the native Wayland commit for now because it breaks mouse input. It's still in commit history if someone wants to work on top of that. For now, you can merge the XWayland changes, and we can look at native Wayland scaling later.

I've fixed the native Wayland scaling fixes and pushed them to a separate branch:

Maia-Everett/XIVLauncher.Core@wayland-hidpi...Maia-Everett:XIVLauncher.Core:wayland-native-hidpi

I can make a separate PR after this is merged. I'll keep this PR focused on XWayland.

I checked under KDE Plasma 6.1 with X11, and the scaling issue is present there too, so it's not just XWayland.